The present application relates generally to an improved data processing apparatus and method and more specifically to an apparatus and method for providing a set of viewports where each viewport provides a different view of content in a directory.
A directory server provides a centralized directory service for intranet, network, and extranet information. Directory servers integrate with existing systems and act as a centralized repository for the consolidation of employee, customer, supplier, and partner information. Directory servers may be extended to manage user profiles and preferences, as well as extranet user authentication.
Usually, the front end of a directory server is a lightweight directory access protocol (LDAP). LDAP provides a common language that client applications and directory servers use to communicate with one another. LDAP is a “lightweight” version of the directory access protocol (DAP) used by the International Organization for Standardization (ISO) X.500 standard. DAP gives any application access to the directory via an extensible and robust information framework, but at an expensive administrative cost. DAP uses a communications layer (Open Systems Interconnection (OSI) stack) that is not the Internet standard Transmission Control Protocol/Internet Protocol (TCP/IP) protocol and has complicated directory-naming conventions. The current version of LDAP is 3 (LDAPv3), which is described by several Request for Comments (RFCs), RFCs-2251 through 2256 and others. There is currently a Lightweight Directory Access Protocol V3 Revision Working Group (LDAPbis) Internet Engineering Task Force (IETF) working group which is revising these old RFCs.
A directory server stores information in a tree-like hierarchical structure and may be characterized by very fast read operations, fairly static data, hierarchical, clients use standard LDAP protocol, and loosely coupled replication. LDAP preserves the best features of DAP while reducing administrative costs. LDAP uses an open directory access protocol running over TCP/IP and uses simplified encoding methods. LDAP retains the X.500 standard data model and can support millions of entries for a modest investment in hardware and network infrastructure.
In large corporations that employ an enterprise directory where all user, group, authentication, and application support has been consolidated, the directory tends to have multiple audiences, multiple use cases, and supports numerous applications. The directory may contain data intended for Intranet use by employees, as well as business-to-consumer (B2C) data about and for customers. In fact there may be different categories of customers who interact with the directory in different ways, via different interfaces. Current solutions to support the different categories of customers who interact with the directory in different ways may include;                1) Access control information may be set up in the directory to control access based on user group membership. However, setting up access control information requires careful attention to maintaining proper group memberships, increasing in complexity as the number of different categories of users increases, and the use of groups does not scale well with many directories.        2) Different applications may be custom designed to provide the intended interaction to each of the user categories. However, customizing different applications places a burden on the applications to handle proper access control, and may not be applied in an environment with off-the-shelf apps included.        3) Partial (filtered) replication may be used to create multiple replicas of the directory, each containing the appropriate subset of the data for access by one or more categories of users. However, partial replication dramatically increases the administrative burden to maintain multiple copies of the directory, monitor the on-going replication activity, and duplicate data.        